Readme file for the NetWare Requester for OS/2 v2.0 included in the NetWare Workstation Kit for OS/2 v2.0 October 1992 This Readme file explains known software problems and issues, as well as corrections to the documentation. This Readme replaces the Readme sent with the general release of the NetWare Workstation Kit for OS/2 v2.0. This readme applies to the general release software, not NSD#2. General ------- #1 This release does not support the remote-boot (RIPL) feature. Remote-boot support will be included in an NSD at a later date. #2 If you want to establish file server connections and map drives before executing the OS/2 startup folder or the STARTUP.CMD file, add the following line to your CONFIG.SYS file: CALL=C:\NETWARE\LOGIN.EXE SERVER\USER If you installed the Requester files in a location other than the default, replace "C:\NETWARE" with the location of the Requester files. This capability is useful for automatically starting programs from network drives. #3 The NetWare Requester manual incorrectly states that DBNMPIPE.EXE is found on the NetWare Requester for OS/2 v2.0 diskette. DBNMPIPE.EXE is part of the SQL Server software from Microsoft. Virtual DOS and Windows Sessions -------------------------------- NOTE: Use the virtual session information in this readme file rather than the information in chapter 8 of the NetWare Requester for OS/2 v2.0 manual. The information in this readme is more recent. #4 Network support in virtual sessions can be private, global, or IPX/SPX-only. When you install the NetWare Requester with support for virtual sessions, the default support is for IPX/SPX-only. IPX/SPX-only becomes private support when you run NETX.COM in a session. Note: By default, the NetWare Resources Property will be set to Private. However, until you run NETX.EXE, the support is actually IPX/SPX-only. IPX/SPX-ONLY. All DOS and Windows sessions set up for IPX/SPX-only support do not have a NetWare connection, but they do provide support for DOS IPX and SPX applications and access to OS/2-redirected NetWare resources such as drives and printers. IPX/SPX-only support uses the DOSVIPX.SYS (for VM Boot sessions) and VIPX.SYS programs included on the NetWare Requester diskette. PRIVATE. All DOS and Windows sessions set up for private login support have their own connection to the NetWare network. Private login support uses the DOSVIPX.SYS, VIPX.SYS, and NETX.EXE programs included on the NetWare Requester for OS/2 diskette. GLOBAL. All DOS, and Windows sessions set up for global login support share a single connection to a NetWare network with OS/2 sessions. Global login support uses the DOSVIPX.SYS, VIPX.SYS, VSHELL.SYS, and DOSVSHLL.SYS programs included on the NetWare Requester diskette. #5 Many of your non-NetWare-aware programs will function in an IPX/ SPX-only environment, and since this environment requires the least setup, you should try your programs in this environment first. If the programs do not run properly in an IPX/SPX-only environment, run them in a private or global environment. The private login environment provides support for all NetWare features and utilities. The global environment does not currently support the FILER utility and programs that use temporary drive connections. Support for these features will be provided at a later time. #6 For all virtual sessions you start, the COMSPEC variable must point to the correct version of DOS. If you are running the version of DOS included with OS/2, the COMSPEC variable should be set as follows: SET COMSPEC=drive:\OS2\MDOS\COMMAND.COM Replace "drive" with the letter of your boot drive. If you are running another version of DOS, the COMSPEC variable should point to the location of the COMMAND.COM file for that version. Be sure to check the COMSPEC variable definition AFTER logging in. #7 If you are running a Windows program that uses the IPX or SPX protocol but does not access a NetWare server, you must load the TBMI.COM program BEFORE running the program. Load TBMI automatically before each session by including the following line in your AUTOEXEC.BAT file: drive:\path\TBMI.COM Replace "drive:\path" with the location of the TBMI.COM file. By default, TBMI.COM is copied to the \NETWARE directory with the other Requester files. For more information about TBMI, see the NetWare documentation for Windows workstations. #8 When you log out from an OS/2 session, the drive for your login directory is drive L:. When you log out from a virtual DOS session, the drive for your login directory is the last physical drive plus one. For example, if your last physical drive is C:, the drive for your login directory will be D:. This means that the drive you see after logging out depends on whether you log out from a DOS or an OS/2 session. Private Virtual Sessions ------------------------ #9 To set up private login support, do the following steps. A) Make sure network support for virtual sessions was installed when you installed the Requester. If it wasn't installed, use the Requester installation procedure to edit the CONFIG.SYS and install virtual session support. B) Open the DOS Settings Notebook for a DOS or Windows icon on your desktop. Modify the Settings notebook for each DOS and Windows icon you want to have private support. C) Select the DOS_LASTDRIVE property and type a drive letter other than Z. The letter should name the last drive you want to appear as local in this session. In this session, NetWare can use all drives occurring after the letter you specify. D) Select the DOS_FILES property and type 214. E) Select the DOS_VERSION property and replace NETX.COM with NETX.EXE. F) To enable the NetWare CAPTURE command, select the DOS_DEVICE property and type the following line: drive:\OS2\MDOS\LPTDD.SYS Replace "drive" with the drive letter of your boot drive. G) Exit the DOS Settings Notebook. H) Load the NETX.EXE program in each session. To load NETX.EXE automatically in ALL DOS and Windows sessions, put the following command in an AUTOEXEC.BAT file in the root of your boot drive: drive:\path\NETX.EXE Replace "drive:\path" with the location of NETX.EXE. By default, NETX.EXE is installed in \NETWARE with the other Requester files. To load NETX.EXE automatically for every session you start from a particular icon, use the Optional Parameters feature on the Settings Notebook for that icon. In the Optional Parameters text entry box, type /K followed by a space, the directory path, and the NETX.EXE filename. The file will then be executed at the start of every session opened from that icon. For example, to load NETX.EXE from the default location, type the following: /K C:\NETWARE\NETX.EXE For more information about Optional Parameters, see your OS/2 documentation. #10 To access the network from a private session booted with a version of DOS other than the one included in OS/2, type the following lines in the CONFIG.SYS file on the DOS diskette or partition you will boot from: DEVICE=drive:\OS2\MDOS\FSFILTER.SYS DEVICE=drive:\path\DOSVIPX.SYS FILES=214 Replace "drive:\path" with the drive and directory where the NetWare Requester files are located. Global Virtual Sessions ----------------------- #11 To set up global login support, do the following steps. A) Make sure network support for virtual sessions was installed when you installed the Requester. If it wasn't installed, use the Requester installation procedure to edit the CONFIG.SYS and install virtual session support. B) Open the DOS Settings Notebook for a DOS or Windows icon on your desktop. Modify the Settings notebook for each DOS and Windows icon you want to have global support. C) Select the NETWARE_RESOURCES property and choose the GLOBAL button. D) Exit the DOS Settings Notebook. #12 To access the network from a global session booted with a version of DOS other than the one included in OS/2, type the following lines in the CONFIG.SYS file on the DOS diskette or partition you will boot from: DEVICE=drive:\OS2\MDOS\FSFILTER.SYS DEVICE=drive:\path\DOSVSHLL.SYS DEVICE=drive:\path\DOSVIPX.SYS Replace "drive:\path" with the drive and directory where the NetWare Requester files are located. #13 The global login support provided with VSHELL does not support programs, such as NETWARE.DRV, that use temporary drive connections. Therefore, run Windows programs that are NetWare- aware--and other programs that encounter problems--in a private rather than a global environment. #14 Drive mappings in DOS differ slightly from drive mappings in OS/2. In OS/2, all mapped drives function like root drives, so drives mapped in OS/2 sessions will show up as root drives in global DOS sessions. Root drives mapped in global DOS sessions will show up as normal drives in OS/2 sessions. Search drive mappings are not used in OS/2. Therefore, search drives mapped in global DOS sessions are ignored in OS/2 sessions. Also, search drives mapped in one DOS session do not apply to other DOS sessions. To eliminate confusion, avoid using search drives completely in a global environment. Instead, obtain the same functionality by setting up your environment as follows: A) If you want to use both global and private login support from the same machine, create two "DOS Full Screen" icons on your desktop. Name one icon for global and one for private. B) Follow the instructions in the NetWare Requester manual to set up the DOS Settings for both the global and private icons. C) Decide which drives you want mapped in your global environment. Decide which of those drives need to be included in a search path. D) Edit your OS/2 login script and include map statements for all NetWare drives. E) Edit your DOS login script and include map root statements for all NetWare drives. Use MAP ROOT rather than MAP for consistency between DOS and OS/2. For easiest maintenance, both login scripts should contain identical map statements. F) Create an OS/2 .CMD file which includes a path statement and the drive letters you want included in the path. The path is where OS/2 searches for .EXE, .CMD, and .COM files. For example, to include drive P: in the search path, type the following line in your .CMD file: SET PATH=%PATH%;p:\; Note: The "%PATH%;" appends whatever you type to the directories that already exist in the PATH statement. If needed, you can also include a drive letter in the data path (DPATH). The DPATH is where OS/2 searches for non-executable, non-.DLL types of files. To include drive P: in the DATH, you would type the following line in your .CMD file: SET DPATH=%DPATH%;p:\; G) Create a DOS .BAT file which includes the same PATH statements you included in the OS/2 .CMD file. You cannot include DPATH statements in the DOS .BAT file. DOS PATH statements are limited to 123 characters, so try to map drives to the exact directories you need and minimize the number of subdirectories you specify. H) Run the .CMD file each time you open an OS/2 session. Run the .BAT file each time you open a DOS global session. One way to do this is to use the Optional Parameters feature on the Settings Notebook. In the Optional Parameters text entry box, type /K followed by a space and the name of the .CMD or .BAT file. The file will then be executed at the start of every session opened from that icon. For more information about PATH, DPATH, Settings, or Optional Parameters, see your OS/2 documentation. #15 DOS applications using VSHELL may not be able to open files on a NetWare v3.11 server if you do not have file scan rights in the directory where the files are located. If your application cannot open a file, check your file scan rights. This does not apply to applications using NETX. #16 The VSHELL program is compatible with 3.x DOS programs. It is not compatible with earlier versions of DOS programs that use NetWare FCB function calls. Named Pipes and SPX ------------------- #17 The maximum number of Named Pipes servers supported on a single network is 100. #18 When you have booted a virtual session with a version of DOS other than the one included in OS/2, you must run the Named Pipes Extender for DOS/Windows (DOSNP.EXE) to use the Named Pipes protocol in that session. In this situation, you can have only one Named Pipes redirector per OS/2 machine--either one DOS/Windows or one OS/2. You do NOT need to run the Named Pipes Extender in virtual sessions booted from the DOS version included with OS/2. Also, you can have more than one redirector in these sessions. #19 The "abort timeout," "listen timeout," "send timeout," and "verify timeout" settings for the Protocol Stack SPX option have an upper limit of 65,535 milliseconds. NetBIOS --------- #20 Some defaults for the NetWare NetBIOS option in the NET.CFG file are incorrectly documented in the NetWare Requester manual. The correct defaults are: COMMANDS Default=128 commands NAMES Default=32 names SESSIONS Default =64 sessions, maximum allowed=64 sessions #21 Chapter 7 of the NetWare Requester manual shows two incorrect examples of modifying the PROTOCOL.INI file. In both cases, you do not need to type "LM10," although "LM10" is shown in the example. The lines added to PROTOCOL.INI should read: [NETBIOS] DriverName = NETBIOS$ ADAPTER0 = IPXNB$,0,16,16,8 #22 To run NetBIOS applications from a virtual session when Extended Services/LAN Services are NOT loaded, do not install Novell's NETBIOS.SYS as instructed in the NetWare Requester manual. Just run the NETBIOS.EXE program in the virtual session. You can only have one NetBIOS connection per OS/2 machine. It can be either one DOS/Windows connection or one OS/2 connection. #23 NetBIOS requests from a virtual Windows session do not go through Novell's Windows NETAPI.DLL as documented in the NetWare Requester manual. The requests go directly to NETBIOS.EXE. Using ODINSUP (Interoperability) -------------------------------- #24 Each time you install IBM communications and networking software, install or reinstall the NetWare Requester afterward. The order that components load in the CONFIG.SYS file is important when running ODINSUP, NetBIOS, or LANSUP. The NetWare Requester installation program automatically orders the statements correctly. #25 The CONFIG.SYS interoperability example in the NetWare Requester manual is incorrect. When running the NetWare Requester with Extended Services or LAN Services, IBM's NETWKSTA.200 file should load after the NWIFS.IFS in the CONFIG.SYS file. Following is a new CONFIG.SYS example. This is an excerpt rather than a complete CONFIG.SYS file. LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\NETWARE; SET PATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;L:\OS2;P:\OS2; SET DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE; DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTOCOL\LANDD.OS2 DEVICE=C:IBMCOM\PROTOCOL\NETBEUI.OS2 rem DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 RUN=C:\IBMCOM\PROTOCOL\LANDLL.EXE RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE RUN=C:\IBMCOM\LANMSGEX.EXE DEVICE=C:\IBMLAN\NETPROG\RDHELP.200 rem --- NetWare Requester statements BEGIN --- DEVICE=C:\NETWARE\LSL.SYS RUN=C:\NETWARE\DDAEMON.EXE DEVICE=C:\NETWARE\TOKEN.SYS DEVICE=C:\NETWARE\ROUTE.SYS DEVICE=C:\NETWARE\ODINSUP.SYS DEVICE=C:\NETWARE\IPX.SYS DEVICE=C:\NETWARE\SPX.SYS RUN=C:\NETWARE\SPDAEMON.EXE rem DEVICE=C:\NETWARE\NMPIPE.SYS rem DEVICE=C:\NETWARE\NPSERVER.SYS rem RUN=C:\NETWARE\NPDAEMON.EXE NP_COMPUTERNAME DEVICE=C:\NETWARE\NWREQ.SYS IFS=C:\NETWARE\NWIFS.IFS RUN=C:\NETWARE\NWDAEMON.EXE rem DEVICE=C:\NETWARE\NETBIOS.SYS rem RUN=C:\NETWARE\NBDAEMON.EXE DEVICE=C:\NETWARE\VIPX.SYS rem --- NetWare Requester statements END --- IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 NOTE: If you are using the ODINSUP driver, you must comment out the corresponding NDIS MAC drivers as directed in the NetWare Requester for OS/2 manual. #26 If you are using Token-Ring network boards that support frame sizes up to 4 KB, type the following lines in your NET.CFG file: Link Support buffers 14 4202 The manual incorrectly says to use "15" instead of "14". #27 If you are using ODINSUP, you do not need to make sure that the Communications Manager transmit buffers are 6 bytes larger than your NetWare Requester Link Support buffers. The NetWare Requester manual is incorrect. #28 The directions in chapter 6 of the manual for increasing the packet size are incorrect for network boards that support frame sizes up to 2 KB. Follow these instructions. If the network boards you're using support only frame sizes up to 2 KB, the default size (buffers 20 1514) is adequate for Ethernet boards. If Token-Ring boards require 2 KB, the size must be increased to: Link Support buffers n 2154 Replace "n" with a number less than or equal to 28, so that the maximum memory size of 64 KB is not exceeded. Using LANSUP (Interoperability) ------------------------------- #29 Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN and TOKENEE modules used in the NetWare Requester v1.3. CMGRLAN and TOKENEE are not supported in the NetWare Requester v2.0. LANSUP meets the needs of IBM LAN users who would like to access NetWare but do not have an ODI-compliant network board driver for the board in the workstation. LANSUP supports PC Network II in addition to Ethernet and Token- Ring compatible drivers. ODINSUP and LANSUP provide essentially the same functionality, but each targets a different communications interoperability environment (LANSUP for primary IBM LAN users or ODINSUP for primary NetWare users). To use LANSUP, do the following: A) Install all IBM communication and database products that will be used. B) Install the NetWare Requester for OS/2 v2.0 C) Modify the CONFIG.SYS file by doing the following: - Make sure that LANSUP.SYS is loaded after PROTMAN.OS2 and LSL.SYS. If the CONFIG.SYS contains a statement to load an ODI driver, replace the ODI driver name with LANSUP.SYS. If the CONFIG.SYS does not contain an ODI driver, add the statement to load LANSUP.SYS. - Make sure that the NetWare NWIFS.IFS loads before the OS/2 NETWKSTA.200 file. Following is an excerpt from a CONFIG.SYS file for using LANSUP: LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\NETWARE; SET PATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;L:\OS2;P:\OS2; SET DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE; DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTOCOL\LANDD.OS2 DEVICE=C:IBMCOM\PROTOCOL\NETBEUI.OS2 DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 RUN=C:\IBMCOM\PROTOCOL\LANDLL.EXE RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE RUN=C:\IBMCOM\LANMSGEX.EXE DEVICE=C:\IBMLAN\NETPROG\RDHELP.200 rem --- NetWare Requester statements BEGIN --- DEVICE=C:\NETWARE\LSL.SYS RUN=C:\NETWARE\DDAEMON.EXE rem Replace TOKEN.SYS with LANSUP.SYS DEVICE=C:\NETWARE\LANSUP.SYS DEVICE=C:\NETWARE\ROUTE.SYS DEVICE=C:\NETWARE\IPX.SYS DEVICE=C:\NETWARE\SPX.SYS RUN=C:\NETWARE\SPDAEMON.EXE rem DEVICE=C:\NETWARE\NMPIPE.SYS rem DEVICE=C:\NETWARE\NPSERVER.SYS rem RUN=C:\NETWARE\NPDAEMON.EXE NP_COMPUTERNAME DEVICE=C:\NETWARE\NWREQ.SYS IFS=C:\NETWARE\NWIFS.IFS RUN=C:\NETWARE\NWDAEMON.EXE rem DEVICE=C:\NETWARE\NETBIOS.SYS rem RUN=C:\NETWARE\NBDAEMON.EXE DEVICE=C:\NETWARE\VIPX.SYS rem --- NetWare Requester statements END --- IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 D) Modify the NET.CFG file by doing the following: - Use the Link Driver option to enable the frame types supported by Token-Ring, Ethernet, or PC Network II. You must enable at least one frame type. Supported frame types are: token-ring, token-ring_snap for Token-Ring ethernet_802.2 and ethernet_snap for Ethernet ibm_pcn2_802.2 and ibm_pcn2_snap for PC Network II For example, to enable both allowable frame types for Token-Ring, type the following: Link Driver LANSUP frame token-ring frame token-ring_snap - Use the Link Driver statement to specify the node address used by the network board. The node address is normally printed on the board. For example, to enable one PC Network II frame type and set the node address, type the following: Link Driver LANSUP node address 080000A564CBL frame ibm_pcn2_802.2 The node address must be a 6-byte hexadecimal number (12 characters) followed by the letter L or M (standing for LSB or MSB). Note: If you do not know the node address, you can type a "dummy" address and reboot the machine. At machine start-up, the correct address will be displayed. - Use the Link Support statement to increase the size of the packet to be transmitted. For Ethernet network boards that only support frame sizes up to 2 KB, the default size (buffers 20 1514) is adequate. If Token-Ring boards require 2 KB, the size must be increased to Link Support buffers n 2154 Replace "n" with a number less than or equal to 28, so that the maximum memory size of 64 KB is not exceeded. For Token-Ring boards that support frame sizes up to 4 KB, type the following statement: Link Support buffers 14 4202 - (Optional) Change the default for whether addresses are transmitted in canonical (least significant bit first) or non-canonical (most significant bit first) form. By default, Token-Ring and PC Network II frames are in non-canonical (or MSB) format and Ethernet frames are canonical (LSB). To change the default, add an LSB or MSB keyword after the frame statement. For example, to enable both Token-Ring frame types, and override the non-canonical form for one of the frame types, add the following statement: Link Driver LANSUP frame token-ring frame token-ring_snap lsb Note: MSB and LSB can only be used if the network board driver supports Octet Bit Reversal (OBR).